Lås upp prestanda för frontend: En djupdykning i Resource Timing API

I webbutvecklingens värld är hastighet inte bara en funktion; det är ett grundläggande krav för en positiv användarupplevelse. En långsamt laddande webbplats kan leda till högre avvisningsfrekvens, lägre användarengagemang och i slutändan en negativ inverkan på affärsmålen. Medan verktyg som Lighthouse och WebPageTest ger ovärderlig diagnostik på hög nivå, representerar de ofta ett enskilt, syntetiskt test. För att verkligen förstå och optimera prestanda för en global publik behöver vi mäta upplevelsen för riktiga användare, på deras enheter, på deras nätverk. Det är här Real User Monitoring (RUM) kommer in, och ett av dess mest kraftfulla verktyg är Resource Timing API.

Denna omfattande guide tar dig med på en djupdykning i Resource Timing API. Vi kommer att utforska vad det är, hur man använder det och hur man omvandlar dess granulära data till handlingsbara insikter som dramatiskt kan förbättra din applikations laddningsprestanda. Oavsett om du är en erfaren frontend-utvecklare eller precis har påbörjat din resa med prestandaoptimering, kommer denna artikel att utrusta dig med kunskapen för att dissekera och förstå nätverksprestandan för varje enskild tillgång på din sida.

Vad är Resource Timing API?

Resource Timing API är ett webbläsarbaserat JavaScript-API som tillhandahåller detaljerad nätverkstidsdata för varje resurs som en webbsida laddar ner. Tänk på det som en mikroskopisk lins för din sidas nätverksaktivitet. För varje bild, skript, stilmall, typsnitt och API-anrop (via `fetch` eller `XMLHttpRequest`) fångar detta API en högupplöst tidsstämpel för varje steg i nätverksbegäran.

Det är en del av en större svit av Performance API:er, som arbetar tillsammans för att ge en holistisk bild av din applikations prestanda. Medan Navigation Timing API fokuserar på huvuddokumentets livscykel, zoomar Resource Timing API in på alla de beroende resurser som huvuddokumentet begär.

Varför är det så viktigt?

• Granularitet: Det går bortom ett enskilt "sidladdningstid"-mått. Du kan se exakt hur lång tid DNS-uppslag, TCP-anslutning och nedladdning av innehåll tog för ett specifikt tredjepartsskript eller en kritisk "hero image".
• Data från riktiga användare: Till skillnad från labb-baserade verktyg körs detta API i dina användares webbläsare. Detta gör att du kan samla in prestandadata från ett brett spektrum av nätverksförhållanden, enheter och geografiska platser, vilket ger dig en sann bild av din globala användarupplevelse.
• Handlingsbara insikter: Genom att analysera denna data kan du peka ut specifika flaskhalsar. Är ett tredjepartsanalysskript långsamt att ansluta? Underpresterar ditt CDN i en viss region? Är dina bilder för stora? Resource Timing API ger de bevis som behövs för att besvara dessa frågor med säkerhet.

Anatomin av en resursladdning: En genomgång av tidslinjen

Kärnan i Resource Timing API är `PerformanceResourceTiming`-objektet. För varje resurs som laddas skapar webbläsaren ett av dessa objekt, som innehåller en mängd information om tid och storlek. För att förstå dessa objekt är det hjälpsamt att visualisera laddningsprocessen som ett vattenfallsdiagram, där varje steg följer det föregående.

Låt oss gå igenom de viktigaste egenskaperna hos ett `PerformanceResourceTiming`-objekt. Alla tidsvärden är högupplösta tidsstämplar mätta i millisekunder från starten av sidnavigeringen (`performance.timeOrigin`).

startTime -> fetchStart -> domainLookupStart -> domainLookupEnd -> connectStart -> connectEnd -> requestStart -> responseStart -> responseEnd

Viktiga tidsegenskaper

• name: URL:en till resursen. Detta är din primära identifierare.
• entryType: En sträng som indikerar typen av prestandapost. För våra ändamål kommer detta alltid att vara "resource".
• initiatorType: Detta är otroligt användbart för felsökning. Det talar om för dig hur resursen begärdes. Vanliga värden inkluderar 'img', 'link' (för CSS), 'script', 'css' (för resurser som laddas inifrån CSS som `@import`), 'fetch' och 'xmlhttprequest'.
• duration: Den totala tiden för resursen, beräknad som responseEnd - startTime. Detta är det övergripande måttet för en enskild resurs.
• startTime: Tidsstämpeln omedelbart innan resursinhämtningen påbörjas.
• fetchStart: Tidsstämpeln precis innan webbläsaren börjar hämta resursen. Den kan kontrollera cacheminnen (HTTP-cache, Service Worker-cache) innan den fortsätter till nätverket. Om resursen serveras från en cache kommer många av de efterföljande tidsvärdena att vara noll.
• domainLookupStart & domainLookupEnd: Dessa markerar starten och slutet på DNS-uppslaget (Domain Name System). Varaktigheten (domainLookupEnd - domainLookupStart) är tiden det tog att översätta domännamnet till en IP-adress. Ett högt värde här kan tyda på en långsam DNS-leverantör.
• connectStart & connectEnd: Dessa markerar starten och slutet på att etablera en anslutning till servern. För HTTP är detta TCP-trevägshandskakningen. Varaktigheten (connectEnd - connectStart) är din TCP-anslutningstid.
• secureConnectionStart: Om resursen laddas över HTTPS, markerar denna tidsstämpel början på SSL/TLS-handskakningen. Varaktigheten (connectEnd - secureConnectionStart) talar om hur lång tid krypteringsförhandlingen tog. Långsamma TLS-handskakningar kan vara ett tecken på felkonfiguration av servern eller nätverkslatens.
• requestStart: Tidsstämpeln precis innan webbläsaren skickar den faktiska HTTP-begäran för resursen till servern. Tiden mellan connectEnd och requestStart kallas ofta för "request queuing"-tid, där webbläsaren väntar på en tillgänglig anslutning.
• responseStart: Tidsstämpeln när webbläsaren tar emot den allra första byten av svaret från servern. Varaktigheten (responseStart - requestStart) är den berömda Time to First Byte (TTFB). En hög TTFB är nästan alltid en indikator på en långsam backend-process eller latens på serversidan.
• responseEnd: Tidsstämpeln när den sista byten av resursen har mottagits, vilket framgångsrikt avslutar begäran. Varaktigheten (responseEnd - responseStart) representerar nedladdningstiden för innehållet.

Egenskaper för resursstorlek

Att förstå resursstorlek är lika viktigt som att förstå tid. API:et tillhandahåller tre nyckelmått:

• transferSize: Storleken i bytes på resursen som överförts över nätverket, inklusive headers och den komprimerade svarskroppen. Om resursen serverades från en cache kommer detta ofta att vara 0. Detta är siffran som direkt påverkar användarens dataabonnemang och nätverkstid.
• encodedBodySize: Storleken i bytes på payload-kroppen *efter* komprimering (t.ex. Gzip eller Brotli) men *före* dekomprimering. Detta hjälper dig att förstå storleken på själva payloaden, separat från headers.
• decodedBodySize: Storleken i bytes på payload-kroppen i sin okomprimerade, ursprungliga form. Att jämföra detta med encodedBodySize avslöjar effektiviteten av din komprimeringsstrategi. Om dessa två siffror ligger mycket nära varandra för en textbaserad tillgång (som JS, CSS eller HTML), fungerar din komprimering troligen inte korrekt.

Server Timing

En av de mest kraftfulla integrationerna med Resource Timing API är egenskapen `serverTiming`. Din backend kan skicka prestandamått i en speciell HTTP-header (`Server-Timing`), och dessa mått kommer att visas i `serverTiming`-arrayen på motsvarande `PerformanceResourceTiming`-objekt. Detta överbryggar klyftan mellan prestandaövervakning för frontend och backend, vilket gör att du kan se databasfrågetider eller API-bearbetningsfördröjningar direkt i din frontend-data.

Till exempel kan en backend skicka denna header:

Server-Timing: db;dur=53, api;dur=47.2, cache;desc="HIT"

Denna data skulle vara tillgänglig i `serverTiming`-egenskapen, vilket gör att du kan korrelera en hög TTFB med en specifik långsam process på backend.

Hur man kommer åt Resource Timing-data i JavaScript

Nu när vi förstår den tillgängliga datan, låt oss titta på de praktiska sätten att samla in den med JavaScript. Det finns två primära metoder.

Metod 1: `performance.getEntriesByType('resource')`

Detta är det enklaste sättet att komma igång. Denna metod returnerar en array av alla `PerformanceResourceTiming`-objekt för resurser som redan har laddats färdigt på sidan vid tidpunkten för anropet.

            
// Vänta tills sidan har laddats för att säkerställa att de flesta resurser fångas upp
window.addEventListener('load', () => {
  const resources = performance.getEntriesByType('resource');

  resources.forEach((resource) => {
    console.log(`Resurs laddad: ${resource.name}`);
    console.log(` - Total tid: ${resource.duration.toFixed(2)}ms`);
    console.log(` - Initiator: ${resource.initiatorType}`);
    console.log(` - Överföringsstorlek: ${resource.transferSize} bytes`);
  });
});

            

              
                Copy
              
            
          

Begränsning: Denna metod är en ögonblicksbild. Om du anropar den för tidigt missar du resurser som ännu inte har laddats. Om din applikation dynamiskt laddar resurser långt efter den initiala sidladdningen, skulle du behöva polla denna metod upprepade gånger, vilket är ineffektivt.

Metod 2: `PerformanceObserver` (Den rekommenderade metoden)

`PerformanceObserver` är ett mer modernt, robust och högpresterande sätt att samla in prestandaposter. Istället för att du pollar efter data, skickar webbläsaren nya poster till din observer-callback när de blir tillgängliga.

Här är varför den är bättre:

• Asynkron: Den blockerar inte huvudtråden.
• Omfattande: Den kan fånga poster från allra första början av sidladdningen och undviker race conditions där ett skript körs efter att en resurs redan har laddats.
• Effektiv: Den undviker behovet av att polla med `setTimeout` eller `setInterval`.

Här är en standardimplementation:

            
try {
  const observer = new PerformanceObserver((list) => {
    list.getEntries().forEach((entry) => {
      // Bearbeta varje resurspost när den kommer in
      if (entry.entryType === 'resource') {
        console.log(`Resurs observerad: ${entry.name}`);
        console.log(` - Time to First Byte (TTFB): ${(entry.responseStart - entry.requestStart).toFixed(2)}ms`);
      }
    });
  });

  // Börja observera 'resource'-poster.
  // 'buffered'-flaggan säkerställer att vi får poster som laddades innan vår observer skapades.
  observer.observe({ type: 'resource', buffered: true });

  // Du kan sluta observera senare om det behövs
  // observer.disconnect();
} catch (e) {
  console.error('PerformanceObserver stöds inte i denna webbläsare.');
}

            

              
                Copy
              
            
          

Alternativet buffered: true är kritiskt. Det talar om för observatören att omedelbart skicka alla `resource`-poster som redan finns i webbläsarens prestandabuffer, vilket säkerställer att du får en komplett lista från början.

Hantera prestandabufferten

Webbläsare har en standardgräns för hur många resurs-timing-poster de lagrar (vanligtvis 150). På mycket komplexa sidor kan denna buffer bli full. När det händer avfyrar webbläsaren en `resourcetimingbufferfull`-händelse, och inga nya poster läggs till.

Du kan hantera detta genom att:

1. Öka bufferstorleken: Använd `performance.setResourceTimingBufferSize(limit)` för att sätta en högre gräns, till exempel 300.
2. Rensa bufferten: Använd `performance.clearResourceTimings()` efter att du har bearbetat posterna för att göra plats för nya.

            
performance.addEventListener('resourcetimingbufferfull', () => {
  console.warn('Resource Timing-bufferten är full. Rensar...');
  // Bearbeta befintliga poster från din observer först
  // Rensa sedan bufferten
  performance.clearResourceTimings();
  // Du kan behöva justera bufferstorleken igen om detta händer ofta
  // performance.setResourceTimingBufferSize(500);
});

            

              
                Copy
              
            
          

Praktiska användningsfall och handlingsbara insikter

Att samla in data är bara det första steget. Det verkliga värdet ligger i att omvandla den datan till handlingsbara förbättringar. Låt oss utforska några vanliga prestandaproblem och hur Resource Timing API hjälper dig att lösa dem.

Användningsfall 1: Identifiera långsamma tredjepartsskript

Problemet: Tredjepartsskript för analys, reklam, kundsupport-widgets och A/B-testning är ökända prestandabovar. De kan vara långsamma att ladda, blockera rendering och till och med orsaka instabilitet.

Lösningen: Använd Resource Timing API för att isolera och mäta påverkan av dessa skript på dina riktiga användare.

            
const observer = new PerformanceObserver((list) => {
  const thirdPartyScripts = list.getEntries().filter(entry => 
    entry.initiatorType === 'script' && 
    !entry.name.startsWith(window.location.origin)
  );

  thirdPartyScripts.forEach(script => {
    if (script.duration > 200) { // Sätt ett tröskelvärde, t.ex. 200ms
      console.warn(`Långsamt tredjepartsskript upptäckt: ${script.name}`, {
        duration: `${script.duration.toFixed(2)}ms`,
        transferSize: `${script.transferSize} bytes`
      });
      // I ett riktigt RUM-verktyg skulle du skicka denna data till din analys-backend.
    }
  });
});

observer.observe({ type: 'resource', buffered: true });

            

              
                Copy
              
            
          

Handlingsbara insikter:

• Lång varaktighet: Om ett skript konsekvent har en lång varaktighet, överväg om det verkligen är nödvändigt. Kan dess funktionalitet ersättas med ett mer högpresterande alternativ?
• Laddningsstrategi: Laddas skriptet synkront? Använd attributen `async` eller `defer` på `<script>`-taggen för att förhindra att det blockerar sidans rendering.
• Ladda selektivt: Kan skriptet laddas villkorligt, endast på de sidor där det är absolut nödvändigt?

Användningsfall 2: Optimera bildleverans

Problemet: Stora, ooptimerade bilder är en av de vanligaste orsakerna till långsamma sidladdningar, särskilt på mobila enheter med begränsad bandbredd.

Lösningen: Filtrera resursposter efter `initiatorType: 'img'` och analysera deras storlek och laddningstider.

            
// ... inuti en PerformanceObserver-callback ...
list.getEntries()
  .filter(entry => entry.initiatorType === 'img')
  .forEach(image => {
    const downloadTime = image.responseEnd - image.responseStart;
    // En stor bild kan ha en hög nedladdningstid och en stor transferSize
    if (downloadTime > 500 || image.transferSize > 100000) { // 500ms eller 100KB
      console.log(`Potentiellt problem med stor bild: ${image.name}`, {
          downloadTime: `${downloadTime.toFixed(2)}ms`,
          transferSize: `${(image.transferSize / 1024).toFixed(2)} KB`
      });
    }
  });

            

              
                Copy
              
            
          

Handlingsbara insikter:

• Hög `transferSize` och `downloadTime`: Detta är en tydlig signal om att bilden är för stor. Optimera den genom att använda moderna format som WebP eller AVIF, komprimera den lämpligt och ändra storlek på den till dess visade dimensioner.
• Använd `srcset`: Implementera responsiva bilder med `srcset`-attributet för att servera olika bildstorlekar baserat på användarens viewport.
• Lazy Loading: För bilder "below the fold" (utanför den synliga delen av sidan), använd `loading="lazy"` för att skjuta upp deras laddning tills användaren rullar dem i sikte.

Användningsfall 3: Diagnostisera nätverksflaskhalsar

Problemet: Ibland är problemet inte själva resursen utan nätverksvägen till den. Långsam DNS, latenta anslutningar eller överbelastade servrar kan alla försämra prestandan.

Lösningen: Bryt ner `duration` i dess beståndsdelar för att peka ut källan till fördröjningen.

            
function analyzeNetworkPhases(resource) {
  const dnsTime = resource.domainLookupEnd - resource.domainLookupStart;
  const tcpTime = resource.connectEnd - resource.connectStart;
  const ttfb = resource.responseStart - resource.requestStart;
  const downloadTime = resource.responseEnd - resource.responseStart;

  console.log(`Analys för ${resource.name}`);
  if (dnsTime > 50) console.warn(` - Hög DNS-tid: ${dnsTime.toFixed(2)}ms`);
  if (tcpTime > 100) console.warn(` - Hög TCP-anslutningstid: ${tcpTime.toFixed(2)}ms`);
  if (ttfb > 300) console.warn(` - Hög TTFB (långsam server): ${ttfb.toFixed(2)}ms`);
  if (downloadTime > 500) console.warn(` - Långsam nedladdning av innehåll: ${downloadTime.toFixed(2)}ms`);
}

// ... anropa analyzeNetworkPhases(entry) inuti din observer ...

            

              
                Copy
              
            
          

Handlingsbara insikter:

• Hög DNS-tid: Din DNS-leverantör kan vara långsam. Överväg att byta till en snabbare global leverantör. Du kan också använda `` för att lösa DNS för kritiska tredjepartsdomäner i förväg.
• Hög TCP-tid: Detta indikerar latens vid etablering av anslutningen. Ett Content Delivery Network (CDN) kan minska detta genom att servera tillgångar från en plats geografiskt närmare användaren. Att använda `` kan utföra både DNS-uppslag och TCP-handskakning tidigt.
• Hög TTFB: Detta pekar på en långsam backend. Arbeta med ditt backend-team för att optimera databasfrågor, förbättra cachning på serversidan eller uppgradera serverhårdvara. `Server-Timing`-headern är din bästa vän här.
• Hög nedladdningstid: Detta är en funktion av resursstorlek och nätverksbandbredd. Optimera tillgången (komprimera, minifiera) eller använd ett CDN för att förbättra genomströmningen.

Begränsningar och att tänka på

Även om det är otroligt kraftfullt har Resource Timing API några viktiga begränsningar att vara medveten om.

Resurser från andra domäner och `Timing-Allow-Origin`-headern

Av säkerhetsskäl begränsar webbläsare de tidsdetaljer som är tillgängliga för resurser som laddas från en annan origin (domän, protokoll eller port) än din huvudsida. Som standard, för en cross-origin-resurs, kommer de flesta tidsegenskaper som `redirectStart`, `domainLookupStart`, `connectStart`, `requestStart`, `responseStart` och storleksegenskaper som `transferSize` att vara noll.

För att exponera dessa detaljer måste servern som hostar resursen inkludera HTTP-headern `Timing-Allow-Origin` (TAO). Till exempel:

Timing-Allow-Origin: * (Tillåter vilken origin som helst att se tidsdetaljerna)

Timing-Allow-Origin: https://www.your-website.com (Tillåter endast din webbplats)

Detta är avgörande när du arbetar med dina egna CDN:er eller API:er på olika subdomäner. Se till att de är konfigurerade att skicka TAO-headern så att du kan få full prestandasynlighet.

Webbläsarstöd

Resource Timing API, inklusive `PerformanceObserver`, har brett stöd i alla moderna webbläsare (Chrome, Firefox, Safari, Edge). För äldre webbläsare kan det dock saknas. Omslut alltid din kod i ett `try...catch`-block eller kontrollera förekomsten av `window.PerformanceObserver` innan du använder den för att undvika fel på äldre klienter.

Slutsats: Från data till beslut

Resource Timing API är ett oumbärligt instrument i den moderna webbutvecklarens verktygslåda. Det avmystifierar nätverksvattenfallet och tillhandahåller de råa, granulära data som behövs för att gå från vaga klagomål om att "sidan är långsam" till precisa, datadrivna diagnoser som "vår tredjeparts-chattwidget har en TTFB på 400ms för användare i Sydostasien."

Genom att utnyttja `PerformanceObserver` för att samla in data från riktiga användare och analysera den fullständiga livscykeln för varje resurs kan du:

• Hålla tredjepartsleverantörer ansvariga för deras prestanda.
• Validera effektiviteten av dina CDN- och cachningsstrategier över hela världen.
• Hitta och åtgärda överdimensionerade bilder och ooptimerade tillgångar.
• Korrelera fördröjningar i frontend med bearbetningstider i backend.

Resan mot en snabbare webb är kontinuerlig. Börja idag. Öppna din webbläsares utvecklarkonsol, kör kodavsnitten från den här artikeln på din egen webbplats och börja utforska den rika prestandadata som har väntat på dig hela tiden. Genom att mäta det som betyder något kan du bygga snabbare, mer motståndskraftiga och mer njutbara upplevelser för alla dina användare, var de än befinner sig i världen.